Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/layouts/admin-access-layout.js`:
- Around line 30-36: The current Route path (`path={`${match.url}/:access_id?`}`
in the Switch) is too permissive and treats any single-segment suffix as an edit
route; replace it with explicit routes: add a Route for the "new" page using
`${match.url}/new` (rendering AdminAccessListPage or AdminAccessForm as
appropriate) and add a separate Route for numeric IDs using a constrained param
like `${match.url}/:access_id(\\d+)` that renders AdminAccessListPage for
editing; keep the Redirect to `match.url` after those Routes and ensure the
order is: new route, numeric-id route, then Redirect so invalid segments still
fall through to the redirect.

In `@src/pages/admin_access/admin-access-list-page.js`:
- Around line 63-79: The getAdminAccess(accessId).then(() => setOpen(true)) call
can reopen the modal with stale data; modify the effect around
useEffect/getAdminAccess to guard against late responses by sequencing or
cancellation: capture the current accessId/isNew (from match.params.access_id
and a flag from /new) or create a request token/AbortController before calling
getAdminAccess, and when the promise resolves verify the token matches the
latest accessId (and still not isNew) before calling setOpen(true) and applying
fetched data (or abort the fetch). Also ensure resetAdminAccessForm is only
applied for the intended /new route by checking the same guard.
- Around line 106-112: handleDeleteAdminAccess currently performs an optimistic
delete via deleteAdminAccess but never refetches the paginated data, leaving
currentPage pointing at an empty page after deleting the last item; change the
flow so that after deleteAdminAccess resolves (or in its success
callback/promise then), call the pagination refetch function (e.g.,
fetchAdminAccessPage or refetchAdminAccess) for the currentPage, and if the
returned page is empty and currentPage > 1, decrement currentPage and refetch
the previous page; update the state that holds currentPage and the page data
accordingly instead of relying only on the reducer’s local filter.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/forms/admin-access-form.js`:
- Around line 33-44: AdminAccessForm currently ignores server-side validation
errors because its props only include { entity, onSubmit, isSaving }; update the
component to accept an errors prop and, inside the component (after useFormik),
watch for changes to that errors prop and call formik.setErrors(errors) and set
relevant fields touched (e.g.,
formik.setTouched(Object.fromEntries(Object.keys(errors||{}).map(k=>[k,true]))))
so Formik displays backend field errors; reference AdminAccessForm, useFormik,
formik.setErrors and formik.setTouched when adding the effect.

---

Nitpick comments:
In `@src/pages/admin_access/__tests__/admin-access-list-page.test.js`:
- Around line 43-45: The test mock currently calls onDelete(row) but the real
MuiTable passes the primitive row id; change the mock delete button to call
onDelete(row.id) so the test exercises the id branch in handleDeleteAdminAccess
(keep onEdit as-is since it expects the full row object). Update the mock in the
test file to pass the row.id identifier to onDelete and verify assertions still
target the id-based behavior.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/forms/admin-access-form.js`:
- Around line 84-88: The getOptionLabel callback uses
member.hasOwnProperty("email"), which triggers no-prototype-builtins warnings
and can fail for objects with a null prototype or shadowed methods; update the
check in getOptionLabel to use Object.prototype.hasOwnProperty.call(member,
"email") (or an equivalent safe check like Boolean(member.email)) so the label
generation for the member (first_name, last_name, email/id) remains identical
but avoids prototype-builtins issues.

---

Outside diff comments:
In `@src/pages/admin_access/admin-access-list-page.js`:
- Around line 77-80: The current call to getAdminAccess(accessId).then(() =>
setOpen(true)) lacks error handling; wrap it with a .catch to handle rejection
by closing the dialog and returning the user to the list. Specifically, update
the branch that calls getAdminAccess(accessId) so failures call setOpen(false)
(or ensure the dialog remains closed) and perform a navigation back to the
admin-access list (e.g., via the app's router helper or history push/replace)
and/or show a user-facing error; keep getAdminAccess and setOpen as the
referenced symbols when implementing the .catch handler.
- Around line 150-162: The summits and members table columns in the columns
array created in useMemo lack render formatters, so the table tries to render
arrays of objects (causing [object Object] or invalid React children); update
the column definitions for columnKey "summits" and "members" to add a render
function (or the MuiTable column renderer prop name used in this codebase) that
maps each summit object to summit.name (joined by commas) and each member object
to a display name like `${first_name} ${last_name}` (also joined by commas)
before returning the string/JSX for the cell; locate the columns definition in
admin-access-list-page.js (the useMemo that defines columns) and add these
renderers to those two column entries.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/pages/admin_access/__tests__/admin-access-list-page.test.js`:
- Around line 104-109: The test currently never sets baseState.loading so the
"in-flight save disables controls" assertions don't exercise the real guard;
update the test to drive loading by either (a) calling renderPage with a store
state where baseState.loading is > 0 (e.g. 1) to simulate an in-flight save, or
(b) mock the save thunk to dispatch the loading start action before resolving so
the component sees loading > 0; locate renderPage and mockStore usage and the
save thunk mock to implement one of these changes (adjust renderPage invocation
or the thunk mock) so the disabled-state assertions run against an actual
loading state.

In `@src/pages/admin_access/admin-access-form-popup.js`:
- Around line 1-2: The component currently relies on the global loading prop
which is set after an async token fetch, allowing rapid repeated submits; add a
component-scoped in-flight guard (e.g., local state boolean isSaving or
isSubmitting) and use it at the start of the submit handler to short-circuit
duplicate calls to saveAdminAccess; set isSaving=true immediately before
initiating the async/token fetch, reset it in a finally block after
saveAdminAccess completes or errors, and keep the existing checks against the
global loading prop (reference the submit handler that calls saveAdminAccess,
the saveAdminAccess dispatch, and the loading prop) so multiple rapid clicks
cannot trigger concurrent saves.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/actions/admin-access-actions.js`:
- Around line 94-95: The snackbarErrorHandler may be swallowing promise
rejections instead of propagating them, causing error handling chains to break.
In the getAdminAccess and deleteAdminAccess functions, replace the `.then(() =>
stopLoading())` pattern with a `.finally(() => stopLoading())` block to ensure
the loading state is cleared regardless of request success or failure, similar
to how saveAdminAccess already implements this pattern. Verify that
snackbarErrorHandler explicitly returns a rejected Promise after displaying the
error message so that downstream catch handlers in AdminAccessListPage and other
callers can properly handle the rejection chain.

In `@src/components/forms/admin-access-form.js`:
- Around line 51-57: The useEffect hook in admin-access-form.js returns early
when serverErrors is empty without clearing previously set Formik errors,
causing stale error messages to persist even after Redux resets the errors.
Instead of returning early when serverErrors is empty, call formik.setErrors({})
and formik.setTouched({}) to explicitly clear Formik's error and touched state,
ensuring it stays synchronized with the Redux state being reset.